走到第 28 天，一起 AA 已經有共享帳本、各自填寫消費金額、現金面額登記，以及結算前的共同確認。前幾天也把畫面整理成比較一致的馬卡龍色系，透過底部導覽切換帳單、現金與結算。不過，功能出現在畫面上，不代表兩個人拿著不同裝置，就一定能順利完成整個流程。今天我把重點放在驗收：哪些事情已經有證據，哪些還需要真的操作一次。

之前已經完成不少同一台電腦、不同帳號的測試，也確認過平板能透過區域網路和 QR Code 開啟共享空間。但平板能開啟網址，還不能算是多人分帳驗收完成。登入、加入同一本帳本、各自提交金額、看到對方更新，再一起確認結算，每一段都可能遇到不同問題。因此，今天整理的驗收流程會讓兩個人各自操作自己的裝置，不再由一個人代替所有成員輸入。

在真人測試之前，我先把既有的自動檢查整理成可以一次執行的驗收入口。這次 17 組測試全部通過，涵蓋本機保存與備份、登入狀態、共享帳單、草稿保留、成員權限、結算快照，以及有限現金庫存下的找零與多人交付搜尋。執行結果另外保存成報告，之後修改程式就能用同一個入口重新檢查。不同測試組之間包含重複的回歸案例，因此我用「通過幾組」描述成果，不把它們加總成互不重複的測試數量。

整理時也發現，資料庫更新不能只靠印象判斷。Day 25 和 Day 26 的功能已經寫好，但目前還沒有收到雲端執行成功的確認。為了避免重複執行建立資料表或函式的指令，今天新增一份唯讀檢查，可以查看各階段需要的函式是否存在，以及登入使用者與匿名使用者的呼叫權限。這份檢查本身也經過測試：缺少函式、完整安裝，以及意外開放匿名權限，都能得到對應結果。不過，函式存在仍不代表完整功能驗收通過。

接下來的雙裝置測試，我準備從一筆容易人工核對的帳單開始。Rachel 代墊 300 元，兩人各自填入消費 150 元，共用費用為零。此時另一位成員應該付 Rachel 150 元。如果付款方手上有兩張 100 元，Rachel 有一枚 50 元，預期方案就是付出 200 元，再找回 50 元。用這種簡單情境，可以同時核對帳單、分攤、現金登記和找零結果，也比較容易發現數字在哪個階段出錯。這是準備好的測試案例，尚未記為真人通過。

正常流程之外，我也把容易出問題的情境列進清單。例如，一個人正在修改份額時，另一個人更新帳單，系統應保留草稿並要求重新讀取，不能悄悄蓋掉輸入。帳目或現金改變後，舊結算快照應失效，不能繼續沿用原本方案。已退出的成員不應再讀取或操作帳本，擁有者也不應看到別人的完整現金庫存。這些規則需要在不同裝置上補驗，而不是只看畫面是否漂亮。

今天也把一個重要缺項寫清楚：目前的付款與找零仍然是試算，尚未提供付款方與收款方各自確認完成的功能。鎖定快照是在確認資料版本，不代表錢已經交出去；顯示交付步驟，也不代表系統記錄了收款。後續如果加入雙方付款確認，還需要處理重複按鈕、部分完成後資料改變，以及不同裝置看到同一筆付款進度等問題，不能只加上一個「已付款」按鈕就算完成。

因此，Day 28 今天完成的是自動回歸、資料庫檢查工具、雙裝置驗收清單與文章。真正的兩台裝置操作、使用者回饋，以及雙方付款確認功能仍保留為未完成。這次整理讓我更清楚知道專案走到哪裡，也讓最後幾天的修正有具體依據。對我來說，能明確說出哪些已驗證、哪些還沒完成，也是把作品做好的必要一步。